home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / rfc / rfc1485 < prev    next >
Text File  |  1993-07-27  |  11KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               S. Hardcastle-Kille
  8. Request for Comments: 1485                             ISODE Consortium
  9.                                                               July 1993
  10.  
  11.  
  12.              A String Representation of Distinguished Names
  13.                             (OSI-DS 23 (v5))
  14.  
  15. Status of this Memo
  16.  
  17.    This RFC specifies an IAB standards track protocol for the Internet
  18.    community, and requests discussion and suggestions for improvements.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The OSI Directory uses distinguished names as the primary keys to
  26.    entries in the directory.  Distinguished Names are encoded in ASN.1.
  27.    When a distinguished name is communicated between to users not using a
  28.    directory protocol (e.g., in a mail message), there is a need to have
  29.    a user-oriented string representation of distinguished name.  This
  30.    specification defines a string format for representing names, which is
  31.    designed to give a clean representation of commonly used names, whilst
  32.    being able to represent any distinguished name.  Please send comments
  33.    to the author or to the discussion group <osi-ds@CS.UCL.AC.UK>.
  34.  
  35. Table of Contents
  36.  
  37.    1.  Why a notation is needed...................................... 1
  38.    2.  A notation for Distinguished Name............................. 2
  39.    2.1 Goals......................................................... 2
  40.    2.2 Informal definition........................................... 2
  41.    2.3 Formal definition............................................. 3
  42.    3.  Examples...................................................... 6
  43.    4.  References.................................................... 6
  44.    5.  Security Considerations....................................... 6
  45.    6.  Author's Address.............................................. 7
  46.  
  47. 1.  Why a notation is needed
  48.  
  49.    Many OSI Applications make use of Distinguished Names (DN) as defined
  50.    in the OSI Directory, commonly known as X.500 [CCI88].  This
  51.    specification assumes familiarity with X.500, and the concept of
  52.    Distinguished Name.  It is important to have a common format to be
  53.    able to unambiguously represent a distinguished name.  This might be
  54.    done to represent a directory name on a business card or in an email
  55.  
  56.  
  57.  
  58. Hardcastle-Kille                                                [Page 1]
  59.  
  60. RFC 1485                  Distinguished Names                  July 1993
  61.  
  62.  
  63.    message.  There is a need for a format to support human to human
  64.    communication, which must be string based (not ASN.1) and user
  65.    oriented.  This notation is targeted towards a general user oriented
  66.    system, and in particular to represent the names of humans.  Other
  67.    syntaxes may be more appropriate for other uses of the directory.
  68.    For example, the OSF Syntax may be more appropriate for some system
  69.    oriented uses.  (The OSF Syntax uses "/" as a separator, and forms
  70.    names in a manner intended to resemble UNIX filenames).
  71.  
  72. 2.  A notation for Distinguished Name
  73.  
  74. 2.1 Goals
  75.  
  76.    The following goals are laid out:
  77.  
  78.       o  To provide an unambiguous representation of a distinguished
  79.          name
  80.  
  81.       o  To be an intuitive format for the majority of names
  82.  
  83.       o  To be fully general, and able to represent any distinguished
  84.          name
  85.  
  86.       o  To be amenable to a number of different layouts to achieve an
  87.           attractive representation.
  88.  
  89.       o  To give a clear representation of the contents of the
  90.           distinguished name
  91.  
  92. 2.2 Informal definition
  93.  
  94.    This notation is designed to be convenient for common forms of name.
  95.    Some examples are given.  The author's directory distinguished name
  96.    would be written:
  97.  
  98.       CN=Steve Hardcastle-Kille, OU=Computer Science, O=University
  99.       College London, C=GB
  100.  
  101.    This may be folded, perhaps to display in multi-column format.  For
  102.    example:
  103.  
  104.       CN=Steve Hardcastle-Kille,
  105.       OU=Computer Science,
  106.       O=University College London,
  107.       C=GB
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Hardcastle-Kille                                                [Page 2]
  115.  
  116. RFC 1485                  Distinguished Names                  July 1993
  117.  
  118.  
  119.    Another name might be:
  120.  
  121.       CN=Christian Huitema, O=INRIA, C=FR
  122.  
  123.    Semicolon (";") may be used as an alternate separator.
  124.  
  125.       CN=Christian Huitema; O=INRIA; C=FR
  126.  
  127.    In running text, this would be written as <CN=Christian Huitema;
  128.    O=INRIA; C=FR>.  Another example, shows how different attribute types
  129.    are handled:
  130.  
  131.       CN=James Hacker,
  132.       L=Basingstoke,
  133.       O=Widget Inc,
  134.       CN=GB
  135.  
  136.    Here is an example of a multi-valued Relative Distinguished Name,
  137.    where the namespace is flat within an organisation, and department is
  138.    used to disambiguate certain names:
  139.  
  140.       OU=Sales + CN=J. Smith, O=Widget Inc., C=US
  141.  
  142.    The final example shows quoting of a comma in an Organisation name:
  143.  
  144.       CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB
  145.  
  146. 2.3 Formal definition
  147.  
  148.    A formal definition can now be given.  The structure is specified in
  149.    a BNF grammar in Figure 1.  This BNF uses the grammar defined in RFC
  150.    822, with the terminals enclosed in <> [Cro82].  This definition is
  151.    in an abstract character set, and so may be written in any character
  152.    set supporting the explicitly defined special characters.  The
  153.    quoting mechanism is used for the following cases:
  154.  
  155.       o  Strings containing ",", "+", "="or """, <CR>, "<",
  156.          ">", "#", or ";".
  157.  
  158.       o  Strings with leading or trailing spaces
  159.  
  160.       o  Strings containing consecutive spaces
  161.  
  162.    There is an escape mechanism from the normal user oriented form, so
  163.    that this syntax may be used to print any valid distinguished name.
  164.    This is ugly.  It is expected to be used only in pathological cases.
  165.    There are two parts to this mechanism:
  166.  
  167.  
  168.  
  169.  
  170. Hardcastle-Kille                                                [Page 3]
  171.  
  172. RFC 1485                  Distinguished Names                  July 1993
  173.  
  174.  
  175.       1.  Attributes types are represented in a (big-endian) dotted
  176.           notation.  (e.g., OID.2.6.53).
  177.  
  178.       2.  Attribute values are represented in hexadecimal
  179.           (e.g.,  #0A56CF).
  180.  
  181.    The keyword specification is optional in the BNF, but mandatory for
  182.    this specification.  This is so that the same BNF may be used for the
  183.    related specification on User Friendly Naming [HK93].  When this
  184.    specification is followed, the attribute type keywords must always be
  185.    present.  A list of valid keywords for well known attribute types
  186.    used in naming is given in Table 1.  This is a list of keywords which
  187.    must be supported.  These are chosen because they appear in common
  188.    forms of name, and can do so in a place which does not correspond to
  189.    the default schema used.  A register of valid keyworkds is maintained
  190.    by the IANA.
  191.  
  192.    Only string type attributes are considered, but other attribute
  193.    syntaxes could be supported locally.  It is assumed that the
  194.    interface will translate from the supplied string into
  195.    PrintableString or T.61.
  196.  
  197.    The "+" notation is used to specify multi-component RDNs.  In this
  198.    case, the types for attributes in the RDN must be explicit.  The name
  199.    is presented/input in a little-endian order (most significant
  200.    component last).
  201.  
  202.    When an address is written in a context where there is a need to
  203.    delimit the entire address (e.g., in free text), it is recommended
  204.    that the delimiters <> are used.  The terminator > is a special in
  205.    the notation to facilitate this delimitation.
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hardcastle-Kille                                                [Page 4]
  227.  
  228. RFC 1485                  Distinguished Names                  July 1993
  229.  
  230.  
  231.    <name> ::= <name-component> ( <spaced-separator> )
  232.           | <name-component> <spaced-separator> <name>
  233.  
  234.    <spaced-separator> ::= <optional-space>
  235.                    <separator>
  236.                    <optional-space>
  237.  
  238.    <separator> ::=  "," | ";"
  239.  
  240.    <optional-space> ::= ( <CR> ) *( " " )
  241.  
  242.    <name-component> ::= <attribute>
  243.            | <attribute> <optional-space> "+"
  244.              <optional-space> <name-component>
  245.  
  246.    <attribute> ::= <string>
  247.            | <key> <optional-space> "=" <optional-space> <string>
  248.  
  249.    <key> ::= 1*( <keychar> ) | "OID." <oid>
  250.    <keychar> ::= letters, numbers, and space
  251.  
  252.    <oid> ::= <digitstring> | <digitstring> "." <oid>
  253.    <digitstring> ::= 1*<digit>
  254.    <digit> ::= digits 0-9
  255.  
  256.    <string> ::= *( <stringchar> | <pair> )
  257.             | '"' *( <stringchar> | <special> | <pair> ) '"'
  258.     | "#" <hex>
  259.  
  260.    <special> ::= "," | "=" | '"' | <CR> | "+" | "<" |  ">"
  261.             | "#" | ";"
  262.  
  263.    <pair> ::= "
  264.    <stringchar> ::= any char except <special> or "
  265.  
  266.    <hex> ::= 2*<hexchar>
  267.    <hexchar> ::= 0-9, a-f, A-F
  268.  
  269.                Figure 1:  BNF Grammar for Distinguished Name
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Hardcastle-Kille                                                [Page 5]
  283.  
  284. RFC 1485                  Distinguished Names                  July 1993
  285.  
  286.  
  287.                         Key  Attribute (X.520 keys)
  288.                         ______________________________
  289.                         CN   CommonName
  290.                         L    LocalityName
  291.                         ST   StateOrProvinceName
  292.                         O    OrganizationName
  293.                         OU   OrganizationalUnitName
  294.                         C    CountryName
  295.  
  296.                       Table 1:  Standardised Keywords
  297.  
  298. 3.  Examples
  299.  
  300.    This section gives a few examples of distinguished names written
  301.    using this notation:
  302.  
  303.       CN=Marshall T. Rose, O=Dover Beach Consulting, L=Santa Clara,
  304.       ST=California, C=US
  305.  
  306.       CN=FTAM Service, CN=Bells, OU=Computer Science, O=University
  307.       College London, C=GB
  308.  
  309.       CN=Steve Hardcastle-Kille, OU=Computer Science, O=University
  310.       College London, C=GB
  311.  
  312.       CN=Steve Hardcastle-Kille, OU=Computer Science, O=University
  313.       College London, C=GB
  314.  
  315. 4.  References
  316.  
  317.    [CCI88] The Directory --- overview of concepts, models and services,
  318.            December 1988. CCITT X.500 Series Recommendations.
  319.  
  320.    [Cro82] D.H. Crocker. Standard of the format of ARPA internet text
  321.            messages.  STD 11, RFC 822, University of Delaware,
  322.            August 1982.
  323.  
  324.    [HK93]  S.E. Hardcastle-Kille. Using the OSI directory to achieve
  325.            user friendly naming.  RFC 1484, Department of Computer
  326.            Science, University College London, July 1993.
  327.  
  328. 5.  Security Considerations
  329.  
  330.    Security issues are not discussed in this memo.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Hardcastle-Kille                                                [Page 6]
  339.  
  340. RFC 1485                  Distinguished Names                  July 1993
  341.  
  342.  
  343. 6.  Author's Address
  344.  
  345.    Steve Hardcastle-Kille
  346.    ISODE Consortium
  347.    P.O. Box 505
  348.    London
  349.    SW11 1DX
  350.    England
  351.  
  352.    Phone:+44-71-223-4062
  353.    EMail:  S.Kille@ISODE.COM
  354.  
  355.    DN: CN=Steve Hardcastle-Kille,
  356.    O=ISODE Consortium, C=GB
  357.  
  358.    UFN: S. Hardcastle-Kille,
  359.    ISODE Consortium, GB
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hardcastle-Kille                                                [Page 7]
  395.  
  396.